Software for connecting information, people, systems, and devices such as Microsoft .NET (.NET) provides Extensible Markup Language (XML) based interoperability and is currently being incorporated across clients, servers, services, and tools. For example, products like Microsoft Windows® and Microsoft Office® will use .NET to connect with other systems and applications. For software developers, .NET is manifested in the programming model delivered in the Microsoft® .NET Framework. This framework is an integral Microsoft Windows® component that enables building and running the next generation of software applications and World Wide Web (Web) services. It includes technologies for Web services and Web applications, data access, smart client applications and many others.
Web services are invoked over the Internet by means of industry-standard protocols including Simple Object Access Protocol (SOAP), XML, and Universal Description, Discovery, and Integration (UDDI). They are defined through public standards organizations such as the World Wide Web Consortium (W3C). SOAP is an XML-based messaging technology standardized by the W3C, which specifies all the necessary rules for locating Web services, integrating them into applications, and communicating between them. UDDI is a public registry, offered at no cost, where one can publish and inquire about Web services. .NET includes the use of self-describing software modules, semantically encapsulating discrete functionality, wrapped in and accessible via standard Internet communication protocols like XML and SOAP.
Building an extensible client application requires similar modularity, and the ability to detect and utilize functionality without knowing its origin at build time, even though the modules are loaded into the same application process and interact in a strongly-typed fashion. For example, a development environment might have an integration point at which tools that operate on source code (such as compilers, browsers, formatter/beautifiers, etc.) may integrate into the environment. These tools can be authored by third parties, so the environment itself can not be built with the knowledge of which modules they come from. Thus, the environment must disclose the contract via which it interacts with such tools (including the format of the inputs they require and the outputs they produce, etc.), and then discover and load the installed modules that conform to that contract.
The .NET platform certainly has the ability to dynamically load modules into the current process and utilize the functionality inside them, but currently provides no framework for advertising integration points or recognizing valid contributions to those integration points in an application.
Thus, needed are processes and a system that addresses the shortcomings of the prior art.